Processsor integral technologies for BIOS flash attack protection and notification

ABSTRACT

A system and method for BIOS flash attack protection and notification. A processor initialization module, including initialization firmware verification module may be configured to execute first in response to a power on and/or reset and to verify initialization firmware stored in non-volatile memory in a processor package. The initialization firmware is configured to verify the BIOS. If the verification of the initialization firmware and/or the BIOS fails, the system is configured to select at least one of a plurality of responses including, but not limited to, preventing the BIOS from executing, initiating recovery, reporting the verification failure, halting, shutting down and/or allowing the BIOS to execute and an operating system (OS) to boot in a limited functionality mode.

FIELD

The present disclosure relates to BIOS protection, and, moreparticularly, to BIOS flash attack protection and notification.

BACKGROUND

Computing devices, personal computers, workstations, and servers(hereinafter “computer” or “computers”) typically include a basic inputand output system (BIOS) as an interface between computer hardware(e.g., a processor, chipsets, memory, etc.) and an operating system(OS). The BIOS includes firmware and/or software code to initialize andenable low-level hardware services of the computer, such as basickeyboard, video, disk drive, input/output (I/O) port(s), and chipsetdrivers (e.g., memory controllers) associated with a computermotherboard.

The initialization and configuration of a computer system by firmware,such as Basic Input/Output System (BIOS), occur during a pre-boot phase.After a reset, a processor refers to a predetermined address which ismapped to a non-volatile storage device storing BIOS firmware. Theprocessor sequentially fetches BIOS instructions. These instructionstypically cause the computer to initialize its electronic hardware,initialize its peripheral devices, and boot an operating system. UnifiedExtensible Firmware Interface (UEFI) is a modern BIOS firmwarearchitecture that includes several phases, e.g., security phase (SEC),platform environmental initialization (PEI), driver executionenvironment (DXE) phase, and boot device select (BDS) phase.

Methods of compromising platform firmware are continually beingdeveloped. Compromising platform firmware enables an arsenal of tools toattack a system. Unlike software attacks, compromised firmware is hardto detect and recovery is difficult. Compromised firmware is generallyinvisible to the software layer of a system, including most anti-virusand spyware tools. The invisible and persistent nature of firmware makesit ideal for malicious rootkits. Rootkits are compact and dormantmalicious hooks in the platform that attain highest possible privilegeand lowest visibility to running software. Their primary function is todeliver an attack or provide an API to other viruses and worms on aninfected system.

BIOS is typically stored in flash memory to allow re-programmability.Programming may then be performed without jumper changes for form factorand end-user convenience reasons. This re-programmability results in avulnerability to attack by unauthorized persons and/or malware.Vulnerabilities in BIOS may also be exploited. Through access to thesystem BIOS, a rootkit may be installed that survives system reboot.Anti-virus software may be unable to reliably detect this “persistent”rootkit.

In some situations, BIOS may be stored in true ROM, preventingre-programmability. However, BIOS updates and other legitimatemodifications may be necessary that may be implemented only throughphysical access to the system and the ROM that stores the BIOS.

BRIEF DESCRIPTION OF DRAWINGS

Features and advantages of the claimed subject matter will be apparentfrom the following detailed description of embodiments consistenttherewith, which description should be considered with reference to theaccompanying drawings, wherein:

FIG. 1 illustrates a system (computing platform) consistent with variousembodiments of the present disclosure;

FIG. 2 illustrates an exemplary storage arrangement for informationstored in flash memory consistent with one embodiment of the presentdisclosure;

FIG. 3 illustrates a flow chart of exemplary operations for verifying aBIOS consistent with the present disclosure;

FIG. 4 illustrates another flow chart of exemplary operations forverifying a BIOS consistent with the present disclosure; and

FIG. 5 is a graphical illustration of operations associated with a bootprocess from a reset to OS boot consistent with one embodiment of thepresent disclosure.

Although the following Detailed Description will proceed with referencebeing made to illustrative embodiments, many alternatives,modifications, and variations thereof will be apparent to those skilledin the art.

DETAILED DESCRIPTION

Generally, this disclosure provides systems (and methods) for BIOSstorage attack protection and notification. One example system(computing platform) includes a processor complex that includes aprocessor and off-die non-volatile memory, coupled to the processor. Theprocessor includes a processor initialization module and may includevolatile and non-volatile memory. The processor initialization moduleincludes an initialization firmware verification module and theprocessor complex includes initialization firmware. The initializationfirmware may be written in the Instruction Set Architecture (ISA) of theprocessor and may be stored in the off-die non-volatile memory.

The processor initialization module is configured to be executed firstin response to a reset in order to carry out internal initialization ofthe processor. The reset may be triggered by power on and/or a state ofa model specific register. As used herein, a “reset” is a restart eventwhere flow control is returned to the processor initialization module.Reset includes a power-on-reset where the electrical components of asystem have had power removed prior to the restart. Memory contents mayor may not have been saved for subsequent restoration. Reset furtherincludes a CPU-only reset where power is maintained to the electricalcomponents of a system.

The initialization firmware verification module is configured, as partof the processor initialization module, to verify (i.e., attempt toverify or authenticate) the initialization firmware. The processorinitialization module and/or the initialization firmware verificationmodule may include microcode, circuitry and/or state information storedin processor volatile and/or non-volatile memory. The initializationfirmware is configured to be executed after the initialization firmwareverification module and is configured to verify (i.e., attempt toverify) the BIOS. The initialization firmware may be in the processorISA or an internal format. If the verification of the initializationfirmware and/or the BIOS fails, the system is configured to initiate oneor more response(s). Responses include but are not limited to:preventing the initialization firmware and/or BIOS from executing,initiating recovery (e.g., using out-of-band (OOB) communication),reporting the verification failure using a model-specific register(MSR), halting, shutting down, and/or configuring the computing platformfor operation in “quarantine mode”, allowing the BIOS to execute and anoperating system (OS) to boot. In the quarantine mode, somefunctionality of the system may be made unavailable to the BIOS and OS.

Advantageously, the processor initialization module, initializationfirmware verification module and initialization firmware are integral tothe processor package and are typically unavailable to parties otherthan the processor manufacturer. The initialization firmware provenanceand authenticity may be guaranteed by the processor complex, and theinitialization firmware may run in an isolated execution mode that mayinclude partitioned memory. Unlike a UEFI BIOS, the internal processorinitialization/reset and firmware interfaces may not be made generallyavailable. Allowing operation in the quarantine mode provides limitedoperation when the BIOS verification fails rather than preventingoperation entirely. The BIOS verification failure may then becommunicated to a user. For example, the BIOS may be updated locally,using, e.g., physical jumper settings on the motherboard. In anotherexample, the BIOS may be updated over a network using OOB communicationwith a remote agent.

System Architecture

FIG. 1 illustrates a system consistent with various embodiments of thepresent disclosure. The system 100 of FIG. 1 may include a processorcomplex 102, system memory (RAM) 104 (including OS 150), a platformcontroller hub (PCH) 106, a trusted platform module (TPM) 108, one ormore disk drive(s) 110, a microprocessor subsystem 112, EEPROM 114 and anetwork port 116. The system 100 may be coupled to a remote agent 118via a network 120, and network port 116. Although shown as a separateblock, in some embodiments, TPM 108 may be included in microprocessorsubsystem 112.

As a general overview of system 100, the processor complex 102 isconfigured to execute a processor initialization module 126, includingan initialization firmware verification module 128, and may executeinitialization firmware 130, in response to a system reset, e.g., inresponse to a power on of the system and/or state of a model-specificregister (MSR). The processor initialization module 126 andinitialization firmware verification module 128 may be implemented inmicrocode and/or circuitry. The initialization firmware verificationmodule 128 is configured to verify the initialization firmware 130 andthe initialization firmware 130 is configured to verify the BIOS. Theinitialization firmware verification module 128 may be included on-die(i.e., on the processor 122 die) and/or on-package (i.e., in theprocessor complex 102). For example, dedicated state machines and/orembedded (subordinate) controllers may aid and/or conduct verificationactivities. Such dedicated state machines and/or embedded controllersmay be included in the processor complex 102. For example, theinitialization firmware 130 may perform a cryptographic integrity checkon a cryptographically signed BIOS in order the implement a verifiedboot. If the BIOS verification fails then the processor complex 102 isconfigured to initiate one or more responses. The responses include, butare not limited to, limiting BIOS (and OS) access to and/or disablingsome system technologies (i.e., booting in quarantine mode), updating amodel-specific register (e.g., for reporting), initiating recovery(e.g., via out-of-band (OOB) functionality), preventing operation of theBIOS, preventing booting of the OS, halting, shutting down and/orcombinations thereof. The particular response(s) may be selected atmanufacturing and/or may be selected by updating the processorconfiguration and/or initialization firmware, as described herein.

The processor complex 102 may include a processor (CPU) 122 and off-dienon-volatile memory 124. For example, the off-die non-volatile memory124 may be included in a processor complex package that includes theprocessor 122 and the off-die non-volatile memory 124. In anotherexample, the non-volatile memory 124 may be included in the processor122, e.g., on the same die. The processor 122 may include non-volatilememory 123, processor initialization module 126, initialization firmwareverification module 128, pMSRs 132 and/or eMSRs 133. The initializationfirmware verification module 128 may be included in the processorinitialization module 126 or may be a separate module. The processorinitialization module 126 and/or initialization firmware verificationmodule 128 may include microcode, circuitry and/or state informationstored in volatile and/or non-volatile memory.

On-die and/or on-package non-volatile memory may include a plurality ofnon-volatile memory technologies, including, but not limited to,read-only whose content is set at manufacture (e.g., ROMs), factoryupdatable (e.g., fuses), and/or field-updatable (e.g., fuses, flash).For example, the processor non-volatile memory 123 may be configured tostore microcode and/or other persistent processor state information. Theoff-die non-volatile memory 124 is configured to store initializationfirmware 130. The initialization firmware verification module 128 andinitialization firmware 130 may typically be generated by a processormanufacturer, and stored during the manufacturing process. The processorcomplex 102, including initialization firmware verification module 128and initialization firmware 130, may be relatively secure and generallyinaccessible to attacks by malware. The initialization firmwareverification module 128 (e.g., including fuses and/or reprogrammablestate machines) and initialization firmware 130 may be updated securelyusing, e.g., cryptographic keys.

At least a portion of processor non-volatile memory 123 may beaccessible via one or more model specific registers (MSRs) 132, 133.MSRs may be configured to access and/or control processor configuration.The MSRs may include persistent MSRs (“pMSRs”) 132 and/or ephemeral MSRs(“eMSRs”) 133. Persistent MSRs 132 are configured to persist acrosspower cycles, i.e., may be considered non-volatile. Ephemeral MSRs 133are configured to persist only while the system 100 is powered andrunning, i.e., may be considered volatile. Both pMSRs 132 and eMSRs 133are configured to expose configuration policy and to report processor122 state to third parties. For example, MSRs 132, 133 may be used toturn power management functions on or off, to report errors, to reportstate and/or to turn certain functionality (e.g., hypervisor) on or off.In some embodiments, the eMSRs 133 may be used to report a verificationfailure. For example, a BIOS_VERIFICATION MSR may be set if the BIOSverification fails. Advantageously, configuring the BIOS_VERIFICATIONMSR as an ephemeral MSR 133 allows a BIOS vendor to update the BIOSduring an operational life of the computing platform.

Generally, MSRs 132, 133 may be accessed by third party functions usinga read MSR (e.g., access state) or write MSR instruction (e.g., changecontent of MSR). Some of the MSRs 132, 133 may be “immutable” meaningthat the contents of the immutable MSRs may not be changed by thirdparty out of band or in-band processor ISA code execution action. Forexample, the BIOS_VERIFICATION MSR may be immutable. Malware may beunable to change the contents of an immutable MSR so that the immutableMSR may provide a relatively secure channel for reporting the status of,e.g., the BIOS. In one embodiment, MSRs 132, 133 may include aPlatform_Update MSR configured to trigger execution of initializationfirmware verification module 128 and initialization firmware 130 andtheir associated verification actions. For example, Platform_Update MSRmay trigger execution when written to with a candidate BIOS firmwareupdate.

The processor complex 102 is configured to execute the processorinitialization module 126, including initialization firmwareverification module 128, in response to a system 100 reset. Theprocessor complex 102 may be configured to execute the processorinitialization module 126 and the initialization firmware verificationmodule 128 based on a model specific register, e.g., Platform_UpdateMSR. The initialization firmware verification module 128 is configuredto verify the initialization firmware 130, as described herein. If theverification of the initialization firmware 130 fails, theinitialization firmware verification module 128 may be configured toinitiate one or more response(s), as described herein. For example,processor initialization module 126 and initialization firmwareverification module 128 may include microcode, circuitry and/or stateinformation stored in volatile and/or non-volatile storage. If theverification of the initialization firmware 130 is successful, theprocessor complex 102 is configured to execute the initializationfirmware 130. In this manner, the initialization firmware may be checked(verified) prior to verifying the BIOS. The method and system describedherein is configured to establish a chain of trust, rooted in theprocessor initialization module 126 and the initialization firmwareverification module 128, then extending to initialization firmware 130,and then to BIOS 134.

EEPROM 114 is configured to store BIOS 134, firmware interface table(FIT) 136 and manageability engine (ME) firmware 138. EEPROM 114 isreprogrammable allowing updates to the BIOS 134. The BIOS in 134 may becoupled to network 120 via, e.g., microprocessor subsystem 112 andmanageability engine firmware 138 allowing remote programming. Forexample, EEPROM 114 may be flash memory configured to be reprogrammedlocally or remotely. For example, the flash memory may be NOR-type flashmemory. NOR flash memory is typically byte-writeable, block erasable,smaller than NAND type flash memory (e.g., 1 Megabytes to 16 Megabytesfor NOR versus Gigabytes for NAND) and is typically used forexecute-in-place code. EEPROM 114 may be another type ofre-programmable, non-volatile storage, including, but not limited to,resistive-based and/or charged-based memories (e.g., ferrite-corememory), Phase Change Memory (PCM), Magnetic-based memory (MRAM),Carbon-Nanotube-based non-volatile memory technologies, etc. Suchtechnologies may be termed “Non-Volatile RAM” or “NVRAM” when they arereprogrammable, and may include write-once storage such as fuses/fusearrays. Although NOR-flash and flash memories are discussed herein,other non-volatile memory technologies may be employed, consistent withthe present disclosure. The particular memory technology used may dependon system requirements and is a design choice.

FIG. 2 illustrates an exemplary storage arrangement 200 for informationstored in flash memory 114. The flash may include a BIOS initializationmodule 202, the BIOS 204 and other firmware 206. The BIOS initializationmodule 202 may include a processor reset vector 208, a FIT pointer 210and a FIT structure 212. The FIT structure 212 may include an end-of-FITmarker 214, a BIOS initialization module pointer 216, a verificationcertificate 218 and/or a FIT header 220. The FIT structure 212 of FIG. 2corresponds to FIT 136 of FIG. 1 and the BIOS 204 of FIG. 2 correspondsto BIOS 134 of FIG. 1.

The FIT 136 is configured to provide an interface (i.e., pointers) tofirmware, including BIOS 134, stored in the flash memory 114. If the FIT136 is empty or nullified, a processor bootstrap may be configured torevert to a default processor bootstrap or reset vector address. If theFIT 136 is not empty, it may contain a variety of records that areconfigured to describe executable code and/or data. Such records maycontain pointers and other metadata, such as pointers to a block ofcode/data in the flash memory to be executed in lieu of or in additionto the default reset vector address. The FIT 136, or a similarmechanism, is configured to allow for an alternate specification and/orloading of functionality in lieu of or in addition to default behaviorsimplemented using the processor's default reset vector 208. Thisconfiguration may be useful for system customization and patchingpurposes. The initialization firmware 130 may determine a location ofBIOS 134 in flash 114 using a pointer (e.g., BIOS initialization modulepointer 216) in the FIT structure 212. In some embodiments, theinitialization firmware 130 may use other techniques, e.g., searchingflash 114 and/or platform strapping options, in order to determine thelocation of the BIOS 134.

The BIOS 134 is configured to initialize and test the hardware and toload the OS 150. Re-programmability allows the BIOS 134 to be updated(without replacing the EEPROM 114) but also provides an avenue forattack by malicious programs. Malicious programs that may havecompromised the BIOS 134 typically execute at a relatively highprivilege level so are difficult to detect by conventional anti-malwareprograms. Advantageously, the initialization firmware verificationmodule 128 and initialization firmware 130 consistent with the presentdisclosure are configured to execute prior to the processor 122 fetchingand/or executing the BIOS 134 code, and may therefore detect acompromised BIOS prior to its execution. If the BIOS 134 is compromised(i.e., verification fails), the initialization firmware 130 isconfigured to initiate one or more responses, described herein. Forexample, in response to detection of a compromised system, an alternateFIT entry may be configured to point to a recovery BIOS block in storagestructure 200 in EEPROM 114. In another example, the EEPROM 114 mayinclude a duplicate of BIOS 134 stored in a separate region of EEPROM114 (or another, distinct EEPROM) that may be accessed (decoded) inresponse to detection of a compromised system. In other words, system100 may include a “backup” BIOS configured to be executed ifverification of BIOS 134 fails. The backup BIOS may be stored in EEPROM114 and/or another EEPROM.

Turning again to FIG. 1, microprocessor subsystem 112 may include anembedded microprocessor 140, cache memory 142 and non-volatile memory(ROM) 144. The microprocessor subsystem 112 is configured to executemanageability engine firmware 138 stored in flash memory 114. In thisembodiment, the microprocessor subsystem 112 is coupled to the processorcomplex 102 via the Platform Controller Hub (PCH) 106 and to the network120 and remote agent 118 via the network port 116. The microprocessorsubsystem 112 is configured to provide out-of-band communication. Theout-of-band communication may be between microprocessor subsystem 112and processor complex 102 and/or between system 100 and remote agent118. For example, if verification of BIOS 134 fails, the microprocessorsubsystem 112 (and manageability engine firmware 138) may be configuredto communicate OOB with remote agent 118 to retrieve an updated,verified BIOS from remote agent 118. Advantageously, this may allowremotely updating and/or authenticating the BIOS stored in a flashmemory that has been attacked without requiring actual on-site physicalaccess to the flash memory 114.

Thus, in response to a reset (e.g., associated with a power on and/orbased on a state of a model-specific register), system 100 is configuredto run the processor initialization module 126 to perform aninitialization sequence (i.e., processor 122 initialization phase) andinitialization firmware verification module 128 configured to verifyinitialization firmware 130 included in processor complex 102. System100 is further configured to execute initialization firmware 130 toverify BIOS 134. If verification of initialization firmware 130 and/orBIOS 134 fails, system 100 is further configured to initiate one or moreresponses including, but not limited to, configuring the system(computing platform) to boot in quarantine mode with limitedfunctionality, initiating a recovery process (e.g., via OOBfunctionality), reporting verification status using one or more MSRs,preventing the initialization firmware and/or BIOS from executing,shutting down and/or stopping the processor. Advantageously, unlike BIOS134, the processor initialization module 126, initialization firmwareverification module 128 and initialization firmware 130, included inprocessor complex 102, are relatively inaccessible (e.g., they areon-die or on processor package substrate) and generally do not include apublished interface protocol. This configuration of processorinitialization module 126, initialization firmware verification module128, initialization firmware 130 and processor complex 102 provide a“root of trust” from which BIOS 134 may be verified.

Exemplary Methodology

FIG. 3 illustrates a flow chart 300 of exemplary operations forverifying (authenticating) a BIOS consistent with the presentdisclosure. The operations illustrated in this embodiment may beperformed by circuitry, firmware and/or software modules associated withsystem 100 (e.g., processor complex 102 including CPU 122). Procedureflow may begin at operation 305. Operation 305 includes a reset, e.g., apower-on reset or a CPU-only reset. Operation 310 includes executing aprocessor initialization module. Operation 310 includes executing aninitialization firmware verification module and may include otherprocessor activities associated with powering on. Whether initializationfirmware verifies (i.e., passes verification) may be determined atoperation 315.

If the initialization firmware verifies, the initialization firmware maybe executed at operation 330. Whether the BIOS verifies may bedetermined at operation 335. If the BIOS verifies, a full system bootmay be enabled at operation 340. For example, verification may includeone or more BIOS elements along a default reset vector path or alternateFIT-specified paths or modules. A full system boot means that all systemfunctionality may be available to a BIOS and an OS. Operation 345 mayinclude passing control to the BIOS. For example, the initializationfirmware 130 may pass control of system 100 to BIOS 134. Operation 350may include booting the system including initializing system hardwareand loading the OS.

If the initialization firmware does not verify and/or the BIOS does notverify (i.e., fails verification), one or more response(s) may beinitiated at operation 355. The initialization firmware verificationmodule 128 may be configured to select and initiate these response(s) ifthe initialization firmware fails verification. The initializationfirmware 130 may be configured to select and initiate these response(s)if the BIOS fails verification. The response(s) may include one or moreof operations 360, 365, 370 (and 375), 380, 385, 390 and 395. Operation380 includes halting. For example, processor 122 may be halted atoperation 380. Operation 385 includes preventing execution of theinitialization firmware and/or the BIOS. The system (e.g., system 100)may be shut down at operation 395.

Operation 360 includes booting the system in quarantine mode (i.e., arestricted or limited operational mode). In quarantine mode, some systemfunctionality and/or access to some system components may be disabled.Quarantine mode is configured to allow limited system functionality whenthe initialization firmware and/or BIOS fails verification. For example,“higher” system functions such as a hypervisor may be disabled.Operation 365 includes updating a model specific register (MSR). Theupdate of the model specific register may be configured to communicatethe initialization firmware and/or BIOS verification failure. The modelspecific register may be immutable so that it may not be changed bythird parties providing a relatively secure reporting method. Forexample, the MSR may be updated to communicate the failure withoutcommunicating details of the failure condition. This limited reportingis configured to prevent an attacker from compromising detectionfunctionality using details of the failure condition.

A recovery process may be initiated at operation 370. Operation 370 mayinclude maintaining a cross-reset state configured to allow an initialretry that includes a reset, rolling over to a backup copy of theinitialization firmware and/or BIOS, rolling back to a prior image ofthe initialization firmware and/or BIOS and/or updating theinitialization firmware and/or BIOS. Whether a backup copy of theinitialization firmware is present may depend on properties associatedwith non-volatile memory. A number of retries in operation 370 may belimited. For example, a counter may be implemented that is configured totrigger an exit from the recovery process if the number of retriesreaches a predetermined value. In another example, a roll over or rollback may result in a modification of a persistent state so that asubsequent retry may trigger an exit from the recovery process. Theinitialization firmware and/or BIOS may be updated using secure (i.e.,cryptographic) techniques.

Operation 370 may include updating the initialization firmware and/orBIOS via Out Of Band (OOB) communications. For example, themicroprocessor subsystem 112 of FIG. 1 may be configured to communicateover network 120 to remote agent 118 via OOB communication to retrievean updated, uncompromised BIOS. For example, the updated BIOS may have ahigher monotonic revision than the failed BIOS (e.g., to avoid roll-backattacks to earlier, possibly errant BIOS's). The microprocessorsubsystem 112 may be further configured to reprogram the flash memory114 with the retrieved BIOS. A reset may then be initiated at operation375.

Operation 390 may include implementing a time delay. For example, a timedelay may be inserted between responses. In another example, a timedelay may be inserted between retries in operation 370. The timedelay(s) are configured to reduce a rate of attacks and a rate at whichan attack may be evaluated as a success or a failure.

The responses described by operations 360, 365, 370, 375, 380, 385, 390and 395 may be performed individually or in combination. The particularresponse(s) may be predetermined and stored, e.g., in off-dienon-volatile memory 124. For example, the responses may be selected atvarious times and using various methods including, but not limited to,at manufacturing, at initial operation, by jumpers, by special,protected user initial setup, and/or by updating the initializationfirmware verification module and/or initialization firmware.

Thus, as illustrated in flow chart 300, the processor initializationmodule and initialization firmware verification module may be configuredto execute prior to the initialization firmware and the BIOS in order toverify the initialization firmware and the BIOS. If the initializationfirmware and/or the BIOS fails verification, one or more responses maybe initiated. Advantageously, some of the responses are configured toallow system, e.g., system 100, to operate in a quarantine mode, toupdate the initialization firmware and/or the BIOS and/or to communicatethe initialization firmware and/or the BIOS verification failure.Accordingly, response to a BIOS verification failure is not limited tostopping the system 100.

FIG. 4 illustrates another flow chart 400 of exemplary operations forverifying a BIOS consistent with the present disclosure. The operationsillustrated in this embodiment may be performed by circuitry, firmwareand/or software modules associated with system 100 (e.g., processorcomplex 102 including CPU 122). In FIG. 4, operations associated withverifying the BIOS are included in Init ROM 402 corresponding to InitROM 127 of FIG. 1 and operations associated with the BIOS are includedin UEFI (BIOS) firmware 404 corresponding to BIOS 134.

Program flow may begin at operation 405. Operation 405 may be performedin response to a system reset. Operation 405 may include execution ofthe processor initialization module, including the initializationfirmware verification module and its verification of initializationfirmware, and execution of initialization firmware. If theinitialization firmware verification module successfully verifies theinitialization firmware, the processor may commence execution of theinitialization firmware. Operation 405 may optionally includeinitializing basic memory functions (e.g. establishing system memory)and/or initializing other system elements such as interconnect fabric. AQuick Path Interface is one example of an interconnect fabric that maybe configured to interconnect a processor subsystem with a platformcontroller hub and/or a microprocessor subsystem. Operation 410 includesdetermining whether there is a firmware interface table (FIT) with asigned manifest and an OEM BIOS block in flash memory. For example, insystems that include TPM 108, operation 410 may include confirming theintegrity of the signed manifest by comparing a hash of the manifest toa stored hash value in an NV data register of TPM 108.

If there is not a firmware interface table (FIT) with a signed manifestor there is not an OEM BIOS block in flash memory, operation 415 may beperformed. Operation 415 includes setting an immutable model specificregister (NOT_SIGNED_MSR) and/or halting the processor subsystem. Ifthere is a FIT with a signed manifest and an OEM BIOS block in flashmemory, operation 420 may be performed. Operation 420 includes readingthe signed manifest and associated OEM UEFI BIOS firmware volume.Operation 420 may further include verifying the signed manifest (digitalsignature) with a remote certificate authority (CA). For example,verifying the signed manifest may be performed OOB using themicroprocessor subsystem 112 and manageability engine firmware 138.

Whether the digital signature matches and an associated public key hasnot been revoked and is not expired and an IN_UPDATE_MSR model specificregister is FALSE may be determined at operation 425. If not, a nextentry in the FIT may be read at operation 430. Whether the FIT entrieshave been exhausted may be determined at operation 435. If the FITentries have been exhausted (i.e., no untested entries in the FIT),operation 415 may be performed. If the digital signature matches and anassociated public key has not been revoked and is not expired and anIN_UPDATE_MSR model specific register is FALSE, full boot may be enabledat operation 440. Full boot may include enabling high level technologyand other hardware capabilities.

Operation 445 may include passing control to UEFI BIOS firmware that mayinclude a security phase (SEC), a platform environment initializationphase (PEI) and/or a driver execution environment (DXE). Whether thereis a UEFI firmware update may be determined at operation 450. If thereis a UEFI firmware update, the update may be authenticated using UEFIfirmware validation at operation 455. Operation 460 includes setting amodel specific register IN_UPDATE_MSR, updating the UEFI firmware in theflash memory and clearing the model specific register IN_UPDATE_MSR. Areset may then be initiated at operation 465. If there is not a UEFIfirmware update, UEFI BIOS firmware may finish booting at operation 470.

FIG. 5 is a graphical illustration of operations associated with a bootprocess 500 from a reset to OS boot. The boot process 500 of FIG. 5corresponds to successful verification of BIOS firmware as describedherein. The process 500 may include two phases (phase 1 and phase 2) anda plurality of sub-phases. The process 500 may be initiated with a reset(e.g., power-on or CPU-only) 502. In response to the reset, a processorinitialization module, including a initialization firmware verificationmodule, may be executed as described herein, during sub-phase 504. Theinitialization firmware verification module may be configured to locatethe FIT and to authenticate the initialization firmware as describedherein. The initialization firmware may then verify OEM BIOS and/orenable interconnect fabric (e.g. QPI) and system memory as describedherein during sub-phase 506. Sub-phase 504 and sub-phase 506 areincluded in Phase 1. Phase 1 operations may be performed by processorinitialization module and initialization firmware and may therefore berelatively secure. The UEFI BIOS firmware may then initialize theplatform (e.g., system 100), including SEC, PEI and DXE during sub-phase508. The SEC establishes a temporary memory store, including but notlimited to using a processor Cache As RAM (CAR) in order to execute thePEI core and the PEI modules. When DXE commences, initialized memoryshould be available. The DXE may include PCI, UI, USB, I/O, legacy BIOS,SMBIOS and/or ACPI. The process may end with sub-phase 510, Boot DeviceSelect which corresponds to initiating boot of the operating system.Sub-phase 508 and sub-phase 510 are included in Phase 2. Phase 1includes initialization firmware verification and BIOS verification.Phase 2 includes launch and execution of verified UEFI BIOS firmware andBoot device select.

Generally, this disclosure provides systems (and methods) for BIOSstorage attack protection and notification. One example system includesa processor initialization module that may include processor controland/or data state stored in a processor non-volatile memory andinitialization firmware stored in non-volatile memory in a processorpackage, coupled to the processor. The processor initialization module,including the initialization firmware verification module, is configuredto execute first in response to a reset and the initialization firmwareverification module is configured to verify the initialization firmware.The initialization firmware is configured to execute after verificationby the initialization firmware verification module and, in turn, isconfigured to verify the BIOS. If the verification of the initializationfirmware and/or the BIOS fails, the system is configured to at least oneof: prevent the initialization firmware and/or BIOS from executing,initiate recovery (e.g., using out-of-band (OOB) communication), reportthe verification failure using a model-specific register (MSR), halt theprocessor, shut down and/or allow the BIOS to execute and an operatingsystem (OS) to boot in a limited functionality (“quarantine”) mode. Inthe quarantine mode, some functionality of the system may be madeunavailable to the BIOS and OS.

“Circuitry”, as used in any embodiment herein, may comprise, forexample, singly or in any combination, hardwired circuitry, programmablecircuitry, state machine circuitry, embedded controllers, and/orfirmware that stores instructions executed by programmable circuitry.

The OS 150 may include any general purpose or custom operating system.For example, the OS 150 may be implemented using Microsoft Windows,HP-UX, Linux, or UNIX, and/or other general purpose operating system.

While FIGS. 3, 4 and 5 illustrate methods according various embodiments,it is to be understood that in any embodiment not all of theseoperations are necessary. Indeed, it is fully contemplated herein thatin other embodiments of the present disclosure, the operations depictedin FIGS. 3, 4 and/or 5 may be combined in a manner not specificallyshown in any of the drawings, but still fully consistent with thepresent disclosure. Thus, claims directed to features and/or operationsthat are not exactly shown in one drawing are deemed within the scopeand content of the present disclosure.

Embodiments described herein may be implemented using hardware,software, and/or firmware, for example, to perform the methods and/oroperations described herein. Certain embodiments described herein may beprovided as a tangible machine-readable medium storingmachine-executable instructions that, if executed by a machine, causethe machine to perform the methods and/or operations described herein.The tangible machine-readable medium may include, but is not limited to,any type of disk including floppy disks, optical disks, compact diskread-only memories (CD-ROMs), compact disk rewritables (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMs) such as dynamic and static RAMs,erasable programmable read-only memories (EPROMs), electrically erasableprogrammable read-only memories (EEPROMs), flash memories, magnetic oroptical cards, or any type of tangible media suitable for storingelectronic instructions. The machine may include any suitable processingplatform, device or system, computing platform, device or system and maybe implemented using any suitable combination of hardware and/orsoftware. The instructions may include any suitable type of code and maybe implemented using any suitable programming language.

Thus, in one embodiment the present disclosure provides a method forverifying a basic input/output system (BIOS) of a computing platform.The method includes executing a processor initialization module inresponse to a reset, wherein the processor initialization module isincluded in a processor in the computing platform and the processorinitialization module comprises an initialization firmware verificationmodule; attempting to verify initialization firmware stored innon-volatile memory in a processor package in the computing platformusing the initialization firmware verification module; attempting toverify the BIOS using the initialization firmware wherein the BIOS isincluded in a reprogrammable non-volatile memory; and initiating atleast one response if at least one of the initialization firmware andthe BIOS fails to verify.

In another embodiment, the present disclosure provides a computingplatform. The computing platform includes a processor package including:a processor comprising processor initialization module wherein theprocessor initialization module comprises an initialization firmwareverification module, and an off-die non-volatile memory havinginitialization firmware stored therein. The computing platform furtherincludes a reprogrammable non-volatile memory having basic input/outputsystem (BIOS) firmware stored therein. The processor is configured to:execute the processor initialization module in response to a reset ofthe computing platform, attempt to verify the initialization firmwareusing the initialization firmware verification module, attempt to verifythe BIOS firmware using the initialization firmware and initiate atleast one response if at least one of the initialization firmware andthe BIOS firmware fails verification.

In another embodiment, the present disclosure provides a tangiblecomputer-readable medium including instructions stored thereon which,when executed by one or more processors, cause the one or moreprocessors to perform operations that include executing a processorinitialization module in response to a reset, wherein the processorinitialization module is included in a processor in the computingplatform and the processor initialization module comprises aninitialization firmware verification module; attempting to verifyinitialization firmware stored in non-volatile memory in a processorpackage in the computing platform using the initialization firmwareverification module; attempting to verify the BIOS using theinitialization firmware wherein the BIOS is included in a reprogrammablenon-volatile memory; and initiating at least one response if at leastone of the initialization firmware and the BIOS fails to verify.

The terms and expressions which have been employed herein are used asterms of description and not of limitation, and there is no intention,in the use of such terms and expressions, of excluding any equivalentsof the features shown and described (or portions thereof), and it isrecognized that various modifications are possible within the scope ofthe claims. Accordingly, the claims are intended to cover all suchequivalents.

Various features, aspects, and embodiments have been described herein.The features, aspects, and embodiments are susceptible to combinationwith one another as well as to variation and modification, as will beunderstood by those having skill in the art. The present disclosureshould, therefore, be considered to encompass such combinations,variations, and modifications.

What is claimed is:
 1. A method for verifying a basic input/outputsystem (BIOS) of a computing platform, the method comprising: executinga processor initialization module in response to a reset, wherein theprocessor initialization module is included in a processor in thecomputing platform and the processor initialization module comprises aninitialization firmware verification module; attempting to verifyinitialization firmware stored in non-volatile memory in a processorpackage in the computing platform using the initialization firmwareverification module; attempting to verify the BIOS using theinitialization firmware wherein the BIOS is included in a reprogrammablenon-volatile memory; and initiating at least one response if at leastone of the initialization firmware and the BIOS fails to verify.
 2. Themethod of claim 1, further comprising passing control of the computingplatform to the BIOS, wherein the at least one response comprisesconfiguring the computing platform for operation in quarantine mode withlimited platform functionality.
 3. The method of claim 1, wherein the atleast one response is selected from a plurality of responses comprisingpreventing the initialization firmware from executing, preventing theBIOS from executing, initiating recovery, reporting the verificationfailure using a model-specific register, halting the processor, shuttingdown the computing platform and configuring the computing platform foroperation in quarantine mode with limited platform functionality.
 4. Themethod of claim 1, further comprising updating the initializationfirmware in response to a verification failure of the initializationfirmware.
 5. The method of claim 1, wherein the at least one responsecomprises updating the BIOS over a network using out-of-bandcommunication via a microprocessor subsystem of the computing platform.6. The method of claim 1, further comprising triggering execution of theinitialization firmware verification module and the initializationfirmware in response to writing a candidate BIOS firmware update to amodel-specific register.
 7. A computing platform comprising: a processorpackage comprising: a processor comprising processor initializationmodule wherein the processor initialization module comprises aninitialization firmware verification module, and an off-die non-volatilememory having initialization firmware stored therein; and areprogrammable non-volatile memory having basic input/output system(BIOS) firmware stored therein; the processor configured to: execute theprocessor initialization module in response to a reset of the computingplatform, attempt to verify the initialization firmware using theinitialization firmware verification module, attempt to verify the BIOSfirmware using the initialization firmware and initiate at least oneresponse if at least one of the initialization firmware and the BIOSfirmware fails verification.
 8. The computing platform of claim 7,wherein the processor is further configured to pass control of thecomputing platform to the BIOS and the at least one response comprisesconfiguring the computing platform for operation in quarantine mode withlimited platform functionality.
 9. The computing platform of claim 7,wherein the at least one response is selected from a plurality ofresponses comprising preventing the initialization firmware fromexecuting, preventing the BIOS from executing, initiating recovery,reporting the verification failure using a model-specific register,halting the processor, shutting down the computing platform andconfiguring the computing platform for operation in quarantine mode withlimited platform functionality.
 10. The computing platform of claim 7,wherein the processor is further configured to update the initializationfirmware in response to a verification failure of the initializationfirmware.
 11. The computing platform of claim 7, further comprising amicroprocessor subsystem configured to update the BIOS firmware over anetwork using out-of-band communication.
 12. The computing platform ofclaim 7, further comprising a model-specific register wherein theprocessor is configured to execute the initialization firmwareverification module and the initialization firmware in response to acandidate BIOS firmware being written to the model-specific register.13. A non-transitory computer-readable medium including instructionsstored thereon which, when executed by one or more processors, cause theone or more processors to perform operations comprising: executingprocessor initialization module in response to a reset, wherein theprocessor initialization module is included in a processor in acomputing platform and the processor initialization module comprises aninitialization firmware verification module; attempting to verify, usingthe initialization firmware verification module, initialization firmwareconfigured to be stored in non-volatile memory in a processor package inthe computing platform; attempting to verify the BIOS using theinitialization firmware wherein the BIOS is configured to be included ina reprogrammable non-volatile memory; and initiating at least oneresponse if at least one of the initialization firmware and the BIOSfails to verify.
 14. The computer readable medium of claim 13, whereinthe operations further comprise passing control of the computingplatform to the BIOS, wherein the at least one response comprisesconfiguring the computing platform for operation in quarantine mode withlimited platform functionality.
 15. The computer readable medium ofclaim 13, wherein the at least one response is selected from a pluralityof responses comprising preventing the initialization firmware fromexecuting, preventing the BIOS from executing, initiating recovery,reporting the verification failure using a model-specific register,halting the processor, shutting down the computing platform andconfiguring the computing platform for operation in quarantine mode withlimited platform functionality.
 16. The computer readable medium ofclaim 13, wherein the operations further comprise updating theinitialization firmware in response to a verification failure of theinitialization firmware.
 17. The computer readable medium of claim 13,wherein said at least one response comprises updating the BIOS over anetwork using out-of-band communication via a microprocessor subsystemof the computing platform.
 18. The computer readable medium of claim 13,wherein the operations further comprise triggering execution of theinitialization firmware verification module and the initializationfirmware in response to writing a candidate BIOS firmware update to amodel-specific register.